In the field of electronics various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of custom configurations for programmable integrated circuits. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), complex programmable logic devices (CPLDs), and a wide variety of other logic and memory devices that may be programmed. Often, such PLDs are designed and programmed by a design engineer using an electronic design automation tool that takes the form of a software package.
In the course of generating a design for a PLD, programming the PLD and checking its functionality on the circuit board or in the system for which it is intended, it is important to be able to debug the PLD because a design is not always perfect the first time. Before a PLD is actually programmed with an electronic design, a simulation and/or timing analysis may be used to debug the electronic design. Once the PLD has been programmed within a working system, however, it is also important to be able to debug the PLD in this real-world environment.
And although a simulation may be used to debug many aspects of a PLD, it is nearly impossible to generate a simulation that will accurately exercise all of the features of the PLD on an actual circuit board operating in a complex system. For example, a simulation may not be able to provide timing characteristics that are similar to those that will actually be experienced by the PLD in a running system; e.g., simulation timing signals may be closer or farther apart than what a PLD will actually experience in a real system.
In addition to the difficulties in generating a comprehensive simulation, circuit board variables such as temperature changes, capacitance, noise, and other factors may cause intermittent failures in a PLD that are only evident when the PLD is operating within a working system. Still further, it can be difficult to generate sufficiently varied test vectors to stress the PLD design to the point where most bugs are likely to be observed. For example, a PLD malfunction can result when the PLD is presented with stimuli that the designer did not expect, and therefore did not take into account during the design and simulation of the PLD. Such malfunctions are difficult to anticipate and must be debugged in the context of the complete system. Thus, simulation of an electronic design is useful, but usually cannot debug a PLD completely.
Approaches to debugging internal signals include: manually assigning signals to I/O pins and performing a full recompilation; using an embedded logic analyzer; and routing internal signals to I/O pins and performing an incremental recompilation.
A separate piece of debugging test equipment called a logic analyzer can be used to analyze signals present on the pins of a hardware device, after a full recompilation has been performed. U.S. Pat. Nos. 6,182,247, 6,286,114, 6,247,147 and U.S. Pat. No. 7,036,046 disclose techniques for using an embedded logic analyzer to view internal signals. In addition, viewing internal nodes in a device may be performed as disclosed in U.S. Pat. No. 6,754,862 and Ser. No. 10/629,508. Embedding a logic analyzer into a design is also a technique used in the product “ChipScope ILA” available from Xilinx Inc., of San Jose, Calif. The product “ChipScope Pro” also available from Xilinx uses logic cores built directly into a PLD to allow a user to access internal signals and nodes for debugging.
These techniques may fully recompile the electronic design before debugging can be performed. Once an electronic design for a hardware device such as a PLD has been compiled, though, it may not be desirable to fully recompile the design in order to facilitate a debugging technique. U.S. Pat. No. 7,076,751 entitled “Chip Debugging Using Incremental Recompilation” (which is hereby incorporated by reference) provides a technique to debug internal signals without having to perform a full recompile, thus saving time. These internal signals are routed to an output pin for viewing.
Internal signals that are routed to an output pin, however, will incur routing delays from the internal signal source to the output pin. This delay can make the investigation of the signal very difficult, especially for high-clock-speed designs. A delay in a particular signal could be important if an engineer needs to compare it to another signal for debugging.
In addition, any synchronization of groups of signals will be lost by the time these signals reach debugging test equipment connected to the output pins. In some situations, there are sixteen or thirty-two signals in a bus, and due to delays in their individual routings, these signals will arrive at the output pins at different times and will not be synchronized. When attempting to debug a fast-clock address bus, the address lines would incur different delays due to their individual routings to the output pins and the address word could be difficult to unscramble. The engineer is forced to examine the full trace for this address bus and may need to manually reconstitute the desired address word. Currently, engineers tweak different signals to synchronize them either using their test equipment or based upon their experience and guesswork.
FIG. 1 illustrates a prior art scenario in which two internal signals are viewed at device outputs. Screen shot 10 is a simple example of waveforms for two signals of interest, namely, “input1” and “input2.” Viewed internally at reference numeral 20, both signals are synchronized at their source. These two internal signals have been routed to external pins of the device for debugging and these external signals are labeled “signalprobe1” and “signalprobe1.” When viewed externally at reference number 22, however, it can be seen that these two signals 32 and 34 are no longer synchronized. This loss of synchronization is due to different routing delays within the device.
Given the lack of synchronization of such signals and the difficulties it presents, it would be desirable to have a technique to allow for such signals to be synchronized when viewed at their outputs by debugging test equipment. Such a technique would be especially desirable in the context of an incremental recompilation.